1. Field of the invention
The invention relates to digital rights management in electronic devices. Particularly, the invention relates to the establishment of shared secrets and integrity protection of streamed content in electronic devices applying digital rights management.
2. Description of the Related Art
Since the introduction of digital storage technologies more effective copyright enforcement has become an issue. Especially, the emergence of the Internet as an illicit distribution channel for copyright protected content has created a strong demand for new technologies in copyright protection. One such technology is the Digital Rights Management (DRM). The DRM is a common term for standards and proprietary systems where a given content item is augmented with information that specifies user rights associated with it. The content item may, for example, be an audio recording, video, picture, computer program or simply a document. The user rights may comprise various rules pertaining to the use of the content item. For example, a user may be given a time limit during which the content item can be presented, in other words, rendered to the user. Allowed number of listening times, allowed device identities and partial viewing rights are other examples of rules pertaining to the use of a content item. The DRM requires that the presentation device and the presentation software in it are not hostile, that is, they participate in the enforcement of digital rights. In the presentation device there is usually a DRM agent, or in other words, a DRM engine, which enforces the DRM rights and protects the content items from illicit copying. In order to avoid making a DRM protected content item available for copying, the content item may be encrypted while it is in transit from the network to the presentation device and while it is stored in the presentation device outside of the DRM engine, for example, on a hard disk. In the case of content streaming, the DRM protected content is not downloaded completely to the presentation device before it is presented to the user. However, the streamed content may be provided to the presentation device in an encrypted form always when the presentation device requests to start the streaming of the content. Similarly, the content may be provided via the Internet Protocol (IP) multicast periodically. In any case, the content is provided in an encrypted form.
One standard for the DRM is the one based on Open Mobile Alliance (OMA) DRM specification. The aim of the OMA DRM is to enable controlled consumption of digital media objects by allowing content providers to express content rights. The media objects are content items such as audio clips, video clips, pictures, Java applications and documents. Content items governed by rights are referred to as assets. In the OMA DRM content rights are expressed as document objects, that is, documents written using a Rights Expression Language (REL). In order to specify the rights pertaining to an asset it is associated with a REL object. The association between a REL object and an asset may be specified explicitly by mentioning the asset's identifier in the REL object or implicitly by providing the REL object in a same message together with the asset. In the OMA DRM there are three possible methods for delivering content to a terminal and a DRM agent therein. Content is delivered to a mobile terminal in DRM messages. In a DRM message there is a media object and an optional rights object, that is, a REL object. The first method is called forward-lock. In this method no REL object is associated with the media object. The media object is sent in a DRM message, which has no REL object. Default rights known to MT are applied for the media object. For example, they may prevent further distribution of the media object to any other terminal. The second method is referred to as combined delivery. In the combined delivery, a media object is sent together with the REL object in a DRM message. In the third method the media object and the REL object are provided separately. They may be sent via different transports.
A mobile terminal applying the DRM is equipped with a DRM agent, in other words, a DRM engine. A media object or a media stream, in other words a content stream, is provided via the DRM engine to a media application for presentation to the user. The DRM engine decrypts the media object or content stream, if it has been encrypted for protection. The optional encryption has been performed in a content source using encryption that can only be decrypted using a key available to the DRM engine. The key is typically a symmetric encryption/decryption key. The mobile terminal stores also at least one rule object. The rule object is used by the DRM engine to check the user rights pertaining to a given media object. The DRM engine checks the user rights before making the media object or stream available via the media application for rendering to the user.
Reference is now made to FIG. 1, which illustrates the providing of streaming media and content decryption keys to a terminal that is equipped with a DRM agent in prior art. In FIG. 1 there is a content owner entity, which is, for example, a content owner node 110. From content owner node 110, content is provided to a number of streaming servers such as a streaming server 112, which provide encrypted streams to a number of content clients such as content client 114. The actual content stream is sent from streaming server 112, for example, as a Real-Time Protocol stream. The Real-Time Protocol (RTP) is specified in the Internet Engineering Task Force (IETF) Request For Comments (RFC) number 1889. An RTP stream is carried in Internet Protocol (IP) packets. The transport layer may be, for example, Universal Datagram Protocol (UDP). Content client 114 requests from streaming server 112 the starting of the stream, for example, using Session Initiation Protocol (SIP) specified in RFC 2543 or using Real-Time Streaming Protocol (RTSP) specified in RFC 2326. Content client 114 is used as a content presentation device, on which the user may view and listen to streamed presentations. The rights for viewing a content stream are obtained by content client 114 from a rights issuer node 116. The rights comprise at least a Content Encryption Key (CEK), which is used by the DRM engine to decrypt the streaming content. The rights may also comprise information associated with, for example, the validity period for the rights. Due to the fact that the content encryption key is a symmetric key, it is also used as a content decryption key. The content encryption key is provided to the DRM engine in a format, where it has been encrypted using an asymmetric key associated with the DRM engine for the receiving content client. The asymmetric key may, for example, be a public key for the DRM engine within content client 114. In that way only the DRM engine for content client 114 that has in its possession the private key may obtain the content encryption key.
First, a content stream is encrypted by content owner node 110 with a CEK. It should be noted that the format EKEY (DATA) denotes a data element referred to as DATA encrypted using KEY as the encryption key. The encrypted content stream is delivered to stream server 112, for example, using bulk file downloading as illustrated with arrow 101. Content owner node 110 provides CEK to rights issuer node 116 as illustrated with arrow 102. As content client 114 desires to start streaming the content, it sends a rights request, in which it identifies itself, to rights issuer node 116 as illustrated with arrow 103. The content client is referred to as C in FIG. 1. In reply to the rights request rights issuer node 116 responds with the CEK, which has been encrypted using content client 114 public key (C-PUB). This is illustrated with arrow 104. Thereupon, content client 114 may start receiving a content stream that has been encrypted using the CEK from streaming server 112. The starting of the streaming may be separately requested from streaming server 112 or the stream may be provided continuously via multicasting or broadcasting without separate request from content client 114.
There are problems in a content streaming architecture such as illustrated in FIG. 1. Despite the fact that content streams such as the stream illustrated with arrow 105 are encrypted using the CEK, it is still possible to manipulate the content stream, if an attacker placed between streaming server 112 and content client 114 gains knowledge pertaining to the effect of bit manipulations to the resulting content stream that is rendered to the user. Such knowledge may be gained, if the CEK is not changed frequently enough. However, changing the CEK requires an additional protocol, which complicates the operation of streaming server 112, content client 114 and rights issuer 116. An example of a protocol used for this purpose is the Multimedia Internet Keying (MIKEY) specified in an IETF document draft-ietf-msec-mikey-07.txt (work in progress).